Electronic hardware used for the vast majority of equipment used in both private and professional environments basically is implemented as computing-like devices. Such devices, even though not constituting a general purpose computer, do still constitute a computing device in that they are built from numerous electronic elements or rather electronic devices of different types that are coupled to each other via a bus-like data connection.
During the design phase of such a computing device, of course, the reliability of the flow data and/or transactions within the device is tested to ensure that data and/or instructions are routed throughout the electronic devices along the logically defined paths of the chosen protocol according to the inherent logic of the computing device and the electronic devices contained therein. One basis of such defined flow of data and/or instructions is that each electronic device forming a part of the overall computing system has an address space assigned thereto such that each data and/or instruction packet holding such address is carried along the connections and/or the bus of the computing device such that it is routed to the particular electronic device that has the respective address assigned to it.
The electronic devices (hardware) of such computer devices can be distinguished using classifications of devices. One general classification is the one of transaction initiators—electronic devices capable of initiating a transaction within the system of the computing device autonomously—on the one hand, and devices or slave IPs—electronic devices that are incapable of initiating a transaction within the system of the computing device autonomously—on the other hand. Transaction initiators can, for example, be CPUs (“central processing unit”), DMAs (“Direct Memory Access”), hardware accelerators, and the like. Devices or slave IPs coupled to such transaction initiators are, for example, busses, networks, memories, caches, and the like. Typically, each transaction initiator is coupled to some devices, and the transaction initiator with the devices coupled thereto constitutes a sub-system. However, devices may also be shared amongst initiators.
Such computing devices formed on the basis of hardware platforms bundling numerous electronic devices are designed to fulfill various purposes, very complex ones where they may even form a general purpose computer but also rather simple ones, where computing devices support the design of, for example, consumer electronic devices like, for example, MP3 players and the like. In any event, optimized hardware configuration is desirable to achieve both optimized performance in terms of reliability and speed as well as optimized production costs. Thus, before finalizing the hardware design of such hardware platforms, e.g., the layout and choice of implemented electronic devices, it is general practice to (virtually) simulate the behavior of the developed hardware platform to get a better insight into the data and instruction flow between the various devices forming the platform and to further optimize the logical interaction of the various initiators and devices that form the respective system. To allow such simulation, simulation models are built representing the physical structure of the electronic platform, the data connections, the electronic devices being present, the logical topology, and the like. Such partial models are aggregated to form an overall simulation model of such hardware platforms that allow for performing respective simulation in computer-based simulation environments in order to simulate and potentially optimize the interconnectivity and logical address space. Such electronic circuit simulation uses mathematical models to replicate the behavior of the actual electronic devices and/or circuits used in the platform. Simulating a device's behavior before actually building it greatly improves efficiency and provides insights into the behavior of the overall electronic circuit design. In particular, for integrated circuits (IC), the tooling is expensive, breadboards are impractical, and probing the behavior of internal signals is extremely difficult. Electronics simulators generally integrate an editor, a simulation engine, and model and device libraries. These models typically include generic components or rather common devices like memories, buses, switches, and, in some cases, also cores and also user-defined models.
This modeling and simulation however, is a burdensome activity. In particular, for the time spent by a simulator system for simulating a multi-IP platform (simulation time) there are two main determinants: (1) the time spent by each IP (master device or slave device) for simulating all operations remaining in that IP itself; and (2) the time spent by IPs for communicating amongst each other.
The weight of the first determinant is relevant for rather complex devices (i.e., device models), for example for cores. The weight of the second determinant rather depends on the configuration of the multi-IP platform that is to be modeled. Factors determining this complexity of the configuration are, for example, the topology of the platform, the number and types of IPs or rather devices (not their complexity in itself) constituting the system, and also the specific kind of transaction flows throughout the platform. In particular, traversing the hierarchy of structure elements and the address space can be very time consuming.